Hmm. pointNumber should give the z[pointNumber[0]][pointNumber[1]] value.

We'll have to check with if this is consistent with non-gl heatmap and contour.

@etpinard yes, we do z[y][x] in regular heatmap: https://github.com/plotly/plotly.js/blob/master/src/traces/heatmap/hover.js#L94

but on

https://github.com/plotly/plotly.js/blob/master/src/traces/heatmap/hover.js#L38

we set

ny = index[1]
nx = index[0]

Not sure where do we use pointData.index !== false branch at all, because in every case I could find we calculate nx, ny here, which is basically snapping proper x/y value to bins, which corresponds to z[y][x] data layout and the way data is plotted.

See http://rickyreusser.com/plotly-mock-viewer/#zsmooth_methods

@etpinard yes, these cases are for regular heatmap, switching them to heatmapgl raises the error covered here.

but on

https://github.com/plotly/plotly.js/blob/master/src/traces/heatmap/hover.js#L38

we set

ny = index[1]
nx = index[0]

@etpinard looks consistent to me?

nx = Math.round(pointData.index[1]);
ny = Math.round(pointData.index[0]);

Anyway, the convention is meant to match the way a matrix is printed:

[
  [1, 2, 3],
  [4, 5, 6],
  [7, 8, 9]
]

so the first index is row (y) and the second index is column (x)

@dfcreative the pointData.index !== false case may be for manually triggering hover - ala https://plot.ly/javascript/hover-events/#triggering-hover-events (note you have to scroll the iframe to see the "go" button)

How about covering the relevant cases with tests, then we don't have to argue about this!

It would be nice to fix this thing in 1.29.0. I'll try wrapping this up tomorrow.

Supersedes by #1884